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Abstract 


The National Institute of Standards and Technology (NIST) has 
recently specified the Cipher-based Message Authentication Code 
(CMAC), which is equivalent to the One-Key CBC MAC1 (OMAC1) submitted 
by Iwata and Kurosawa. This memo specifies an authentication 
algorithm based on CMAC with the 128-bit Advanced Encryption Standard 
(AES). This new authentication algorithm is named AES-CMAC. The 
purpose of this document is to make the AES-CMAC algorithm 
conveniently available to the Internet Community. 
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1. Introduction 


The National Institute of Standards and Technology (NIST) has 
recently specified the Cipher-based Message Authentication Code 
(CMAC). CMAC [NIST-CMAC] is a keyed hash function that is based on a 
symmetric key block cipher, such as the Advanced Encryption Standard 
[NIST-AES]. CMAC is equivalent to the One-Key CBC MAC1 (OMAC1) 
submitted by Iwata and Kurosawa [OMACla, OMAC1b]. OMAC1 is an 
improvement of the eXtended Cipher Block Chaining mode (XCBC) 
submitted by Black and Rogaway [XCBCa, XCBCb], which itself is an 
improvement of the basic Cipher Block Chaining-Message Authentication 
Code (CBC-MAC).  XCBC efficiently addresses the security deficiencies 
of CBC-MAC, and OMAC1 efficiently reduces the key size of XCBC. 


AES-CMAC provides stronger assurance of data integrity than a 
checksum or an error-detecting code. The verification of a checksum 
or an error-detecting code detects only accidental modifications of 
the data, while CMAC is designed to detect intentional, unauthorized 
modifications of the data, as well as accidental modifications. 


AES-CMAC achieves a security goal similar to that of HMAC [RFC-HMAC]. 
Since AES-CMAC is based on a symmetric key block cipher, AES, and 
HMAC is based on a hash function, such as SHA-1, AES-CMAC is 
appropriate for information systems in which AES is more readily 
available than a hash function. 


This memo specifies the authentication algorithm based on CMAC with 
AES-128. This new authentication algorithm is named AES-CMAC. 
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2. Specification of AES-CMAC 
2.1. Basic Definitions 


The following table describes the basic definitions necessary to 
explain the specification of AES-CMAC. 


x |] y Concatenation. 
x | | y is the string x concatenated with the string 
y. 
0000 || 1111 is 00001111. 

x XOR y Exclusive-OR operation. 


For two equal length strings, x and y, 
x XOR y is their bit-wise exclusive-OR. 


ceil (x) Ceiling function. 
The smallest integer no smaller than x. 
ceil(3.5) is 4. ceil(5) is 5. 

x «« 1 Left-shift of the string x by 1 bit. 


The most significant bit disappears, and a zero 
comes into the least significant bit. 
10010001 «« 1 is 00100010. 


0^n The string that consists of n zero-bits. 
0^3 means 000 in binary format. 
10^4 means 10000 in binary format. 
10^i means 1 followed by i-times repeated 
zeros. 


MSB (x) The most-significant bit of the string x. 
MSB(10010000) means 1. 


padding (x) 10^i padded output of input x. 
It is described in detail in section 2.4. 


Key 128-bit (16-octet) long key for AES-128. 
Denoted by K. 


First subkey 128-bit (16-octet) long first subkey, 
derived through the subkey 
generation algorithm from the key K. 
Denoted by Kl. 
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Second subkey 128-bit (16-octet) long second subkey, 
derived through the subkey 
generation algorithm from the key K. 
Denoted by K2. 


Message A message to be authenticated. 
Denoted by M. 
The message can be null, which means that the length 
of M is 0. 


Message length The length of the message M in octets. 
Denoted by len. 
The minimum value of the length can be 0. The 
maximum value of the length is not specified in 
this document. 


AES-128 (K,M) AES-128(K,M) is the 128-bit ciphertext of AES-128 
for a 128-bit key, K, and a 128-bit message, M. 


MAC A 128-bit string that is the output of AES-CMAC. 
Denoted by T. 
Validating the MAC provides assurance of the 
integrity and authenticity of the message from 
the source. 


MAC length By default, the length of the output of AES-CMAC is 
128 bits. It is possible to truncate the MAC. 
The result of the truncation should be taken in most 
significant bits first order. The MAC length must be 
specified before the communication starts, and 
it must not be changed during the lifetime of the 
key. 


2.2. Overview 


AES-CMAC uses the Advanced Encryption Standard [NIST-AES] as a 
building block. To generate a MAC, AES-CMAC takes a secret key, a 
message of variable length, and the length of the message in octets 
as inputs and returns a fixed-bit string called a MAC. 


The core of AES-CMAC is the basic CBC-MAC. For a message, M, to be 
authenticated, the CBC-MAC is applied to M. There are two cases of 
operation in CMAC. Figure 2.1 illustrates the operation of CBC-MAC 
in both cases. If the size of the input message block is equal to a 
positive multiple of the block size (namely, 128 bits), the last 
block shall be exclusive-OR'ed with Kl before processing. Otherwise, 
the last block shall be padded with 10^i (notation is described in 
section 2.1) and exclusive-OR'ed with K2. The result of the previous 
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process will be the input of the last encryption. The output of 
AES-CMAC provides data integrity of the whole input message. 


4----- + +----- + +----- + +----- + +----- + 4+---+----+ 
| M1 | | M2 | | Mn | | MI | | M2 | |M_n|10*i| 
+----- + +----- + +----- + +----- + +----- + 4+---+----+ 
| | | per | | | +--+ 
| 4£---» (+) *£---» (+) <- [KL | | +---> (+) +---> (+) <-|K2| 
| | | +--+ | | ME 
4----- + +----- + +----- + +----- + +----- + +----- + 
|AES_K| | |AES_K| | |AES K| |AES_K| | |AES_K| | |AES K| 
+----- + +----- + +----- + +----- + +----- + +----- + 
| | | | | | | | | | 
4----- + 4----- + | 4----- + 4----- + | 
| | 
4----- + +----- + 
| T | | T | 
+----- + +----- + 
(a) positive multiple block length (b) otherwise 


Figure 2.1. Illustration of the two cases of AES-CMAC 


AES K is AES-128 with key K. 

The message M is divided into blocks M 1,...,M n, 

where M i is the i-th message block. 

The length of M i is 128 bits for i = 1,...,n-1, and 

the length of the last block, M n, is less than or equal to 128 bits. 
K1 is the subkey for the case (a), and 

K2 is the subkey for the case (b). 

K1 and K2 are generated by the subkey generation algorithm 

described in section 2.3. 


2.3. Subkey Generation Algorithm 


The subkey generation algorithm, Generate_Subkey(), takes a secret 
key, K, which is just the key for AES-128. 


The outputs of the subkey generation algorithm are two subkeys, K1 
and K2. We write (Kl,K2) := Generate Subkey(K). 


Subkeys K1 and K2 are used in both MAC generation and MAC 
verification algorithms. Kl is used for the case where the length of 
the last block is equal to the block length. K2 is used for the case 
where the length of the last block is less than the block length. 
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Figure 2.2 specifies the subkey generation algorithm. 


EE 


SE Algorithm Generate Subkey + 
dd H+ 
+ + 
+ Input : K (128-bit key) t 
* Output : K1 (128-bit first subkey) * 
* K2 (128-bit second subkey) * 
------------------------------------------------------------------- * 
* * 
* Constants: const Zero is 0x00000000000000000000000000000000 * 
* const, Rb is 0x00000000000000000000000000000087 * 
* Variables: L for output of AES-128 applied to 0^128 * 
* * 
+ Step 1. L := AES-128(K, const Zero); + 
+ Step 2. if MSB(L) is equal to 0 + 
+ then Kl := L << 1; + 
+ else Kl := (L << 1) XOR const Rb; + 
+ Step 3. if MSB(Kl) is equal to 0 + 
+ then K2 := Kl << 1; + 
+ else K2 := (Kl << 1) XOR const Rb; + 
+ Step 4. return Kl, K2; + 
+ + 


THEE ERRRVR ER RH A S I A BM B BM BB B BEBBBER E YTTYTTTTTTEETETTETETA4EGGGGRRABRARRARBR FEET 
Figure 2.2. Algorithm Generate Subkey 

In step 1, AES-128 with key K is applied to an all-zero input block. 

In step 2, Kl is derived through the following operation: 


If the most significant bit of L is equal to 0, Kl is the left-shift 
of L by 1 bit. 


Otherwise, K1 is the exclusive-OR of const Rb and the left-shift of L 
by 1 bit. 


In step 3, K2 is derived through the following operation: 


If the most significant bit of K1 is equal to 0, K2 is the left-shift 
of Kl by 1 bit. 


Otherwise, K2 is the exclusive-OR of const Rb and the left-shift of 
K1 by 1 bit. 


In step 4, (K1,K2) := Generate Subkey(K) is returned. 
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The mathematical meaning of the procedures in steps 2 and 3, 
including const Rb, can be found in [OMAC1a]. 


2.4. MAC Generation Algorithm 


The MAC generation algorithm, AES-CMAC(), takes three inputs, a 
secret key, a message, and the length of the message in octets. The 
secret key, denoted by K, is just the key for AES-128. The message 
and its length in octets are denoted by M and len, respectively. The 
message M is denoted by the sequence of M i, where M i is the i-th 
message block. That is, if M consists of n blocks, then M is written 
as 


- m=mMmi1 || m2 ||... || M (n-1) || mn 


The length of M i is 128 bits for i = 1,...,n-1, and the length of 
the last block M n is less than or equal to 128 bits. 


The output of the MAC generation algorithm is a 128-bit string, 
called a MAC, which is used to validate the input message. The MAC 
is denoted by T, and we write T := AES-CMAC(K,M,len). Validating the 
MAC provides assurance of the integrity and authenticity of the 
message from the source. 


It is possible to truncate the MAC. According to [NIST-CMAC], at 
least a 64-bit MAC should be used as protection against guessing 
attacks. The result of truncation should be taken in most 
significant bits first order. 


The block length of AES-128 is 128 bits (16 octets). There is a 
special treatment if the length of the message is not a positive 
multiple of the block length. The special treatment is to pad M with 
the bit-string 10^i to adjust the length of the last block up to the 
block length. 


For an input string x of r-octets, where 0 <= r < 16, the padding 
function, padding(x), is defined as follows: 


= padding (x) = x | | 10^i where i is 128-8*r-1 

That is, padding(x) is the concatenation of x and a single '1', 
followed by the minimum number of ”0's, so that the total length is 
equal to 128 bits. 


Figure 2.3 describes the MAC generation algorithm. 
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EE 


+ 


Algorithm AES-CMAC 


+ 


EE 


++ ++ ++ 


Input 


Output 


128-bit key ) 

message to be authenticated ) 
length of the message in octets 
message authentication code ) 


anana 


) 


++++++ 


EE EEF EEE EE EFT EEE PEE 


a cR c RRH&R GR R&R x RxGxx«---c--x--«—G« GA 


Constants: const Zero is 0x00000000000000000000000000000000 * 
const Bsize is 16 * 

+ 

Variables: Kl, K2 for 128-bit subkeys + 
M_i is the i-th block (i=1..ceil(len/const_Bsize) ) + 

M last is the last block xor-ed with Kl or K2 + 

n for number of blocks to be processed + 

t£ for number of octets of last block + 

flag for denoting if last block is complete or not + 

+ 

Step 1. (K1,K2) := Generate_Subkey (K); + 
Step 2. n := ceil(len/const Bsize); t 
Step 3. if n=0 + 
then + 

n := 1; + 

flag := false; + 

else + 

if len mod const_Bsize is 0 + 

then flag := true; + 

else flag := false; + 

+ 

Step 4. if flag is true + 
then M last := M n XOR K1; t 

else M last :- padding(M n) XOR K2; t 

Step 5. X :- const Zero; t 
Step 6. for i := 1 to n-1 do t 
begin t 

Y := X XOR M i; + 

X := AES-128(K, Y); + 

end + 

Y := M last XOR X; + 

T := AES-128 (K, Y); + 

Step 7. return T; + 


EE 


Song, 


et al. 


Figure 2.3. Algorithm AES-CMAC 
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In step 1, subkeys Kl and K2 are derived from K through the subkey 
generation algorithm. 


In step 2, the number of blocks, n, is calculated. The number of 
blocks is the smallest integer value greater than or equal to the 
quotient determined by dividing the length parameter by the block 
length, 16 octets. 


In step 3, the length of the input message is checked. If the input 
length is 0 (null), the number of blocks to be processed shall be 1, 
and the flag shall be marked as not-complete-block (false). 
Otherwise, if the last block length is 128 bits, the flag is marked 
as complete-block (true); else mark the flag as not-complete-block 
(false). 


In step 4, M last is calculated by exclusive-OR'ing M n and one of 
the previously calculated subkeys. If the last block is a complete 
block (true), then M last is the exclusive-OR of M n and Kl. 
Otherwise, M last is the exclusive-OR of padding(M n) and K2. 
In step 5, the variable X is initialized. 
In step 6, the basic CBC-MAC is applied to M 1,...,M (n-1),M last. 
In step 7, the 128-bit MAC, T := AES-CMAC(K,M,len), is returned. 
If necessary, the MAC is truncated before it is returned. 

2.5. MAC Verification Algorithm 
The verification of the MAC is simply done by a MAC recomputation. 
We use the MAC generation algorithm, which is described in section 
2.4. 
The MAC verification algorithm, Verify_MAC(), takes four inputs, a 
secret key, a message, the length of the message in octets, and the 


received MAC. These are denoted by K, M, len, and T', respectively. 


The output of the MAC verification algorithm is either INVALID or 
VALID. 


Figure 2.4 describes the MAC verification algorithm. 
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THERE RR dd HER A4 4 4  j. 4 4 4 4 4 4 x BBBAYV4« T 4 B B A A A AL . BM B 1 4 14 444 
t Algorithm Verify MAC t 
uzccccccccc 2: c ccc c 20 22202 2220: 0 20: 20:0: 0:00 0:00 0: 0 0 0]  ] 0:  ] d £2 


+ + 
+ Input ¿K ( 128-bit Key ) + 
+ M ( message to be verified ) t 
t len ( length of the message in octets ) + 
+ 8 “ES ( the received MAC to be verified ) + 
+ Output  : INVALID or VALID + 
+ + 
4------------------------------------------------------------------- t 
t + 
+ Step 1. T* :- AES-CMAC(K,M, len); + 
+ Step 2. if T* is equal to T’ t 
+ then + 
+ return VALID; + 
+ else + 
+ return INVALID; + 


od ob EM fcc dc d 
Figure 2.4. Algorithm Verify MAC 


In step 1, T* is derived from K, M, and len through the MAC 
generation algorithm. 


In step 2, T* and T' are compared. If T* is equal to T', then return 
VALID; otherwise return INVALID. 


If the output is INVALID, then the message is definitely not 
authentic, i.e., it did not originate from a source that executed the 
generation process on the message to produce the purported MAC. 


If the output is VALID, then the design of the AES-CMAC provides 
assurance that the message is authentic and, hence, was not corrupted 
in transit; however, this assurance, as for any MAC algorithm, is not 
absolute. 


3. Security Considerations 


The security provided by AES-CMAC is built on the strong 
cryptographic algorithm AES. However, as is true with any 
cryptographic algorithm, part of its strength lies in the secret key, 
K, and the correctness of the implementation in all of the 
participating systems. If the secret key is compromised or 
inappropriately shared, it guarantees neither authentication nor 
integrity of message at all. The secret key shall be generated in a 
way that meets the pseudo randomness requirement of RFC 4086 
[RFC4086] and should be kept safe. If and only if AES-CMAC is used 
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properly it provides the authentication and integrity that meet the 
best current practice of message authentication. 


4. Test Vectors 


The following test vectors are the same as those of [NIST-CMAC]. The 
following vectors are also the output of the test program in Appendix 


Subkey Generation 


K 


AES-128 (key, 0) 


K1 


2b7e1516 28aed2a6 
7df76b0c lab899b3 
fbeed618 35713366 
f7ddac30 6ae266cc 


abf71588 
3e42£047 
7c85e08f 
f90bclle 


09cf4f3c 
b91b546f 
7236a8de 
e46d513b 


Example 1: 


M 


AES-CMAC 


Example 2: 


M 


AES-CMAC 


Example 3: 


M 


AES-CMAC 


Example 4: 


M 


AES-CMAC 


Song, 


et al. 


«empty string» 
bb1d6929 e9593728 


= 16 
6bclbee2 2e409f96 
070a16b4 6b4d4144 


= 40 

6bclbee2 2e409f96 
ae2d8a57 1e03ac9c 
30c81c46 a35ce411 
dfa66747 de9ae630 


= 64 

6bclbee2 2e409f96 
ae2d8a57 1e03ac9c 
30c81c46 a35ce411 
f69f2445 df4f9b17 
51f0bebf 7e3b9d92 


e93d7e11 
£79bdd9d 


e93d7e11 
9eb76fac 


30ca3261 


e93d7e11 
9eb76fac 
e5fbcl19 
ad2b417b 
fc497417 


Informational 


7393172a 
d04a287c 


7393172a 
45af8e51 


1497c827 


7393172a 
45af8e51 
1a0a52ef 
e66c3710 
79363cfe 
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Appendix A. Test Code 


This C source is designed to generate the test vectors that appear in 
this memo to verify correctness of the algorithm. The source code is 


not intended for use in commercial products. 


[RRR KKK KK KKK KKK KKK KKK KKK KKK kk KC KKK KKK KKK kck ck ck KKK kck ck kck ck kck ck ckckck sk sk e kk / 


/* AES-CMAC with AES-128 bit Kf 
/* CMAC Algorithm described in SP800-38B */ 
/* Author: Junhyuk Song (junhyuk.song@samsung.com) x 
fe Jicheol Lee (jicheol.lee@samsung.com) xU, 


[RK KKK KKK KKK KKK KKK KK KKK C kk KKKK KKK KKK KKK KKKK KKK KKK kok ck KKK KKK sk KK | 


#include <stdio.h> 


/* For CMAC Calculation */ 
unsigned char const_Rb[16] = { 
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x87 
}; 
unsigned char const_Zero[16] = { 
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 
E 


/* Basic Functions */ 


void xor 128(unsigned char *a, unsigned char *b, unsigned char *out) 


{ 
int i; 
for (i=0;i<16; i++) 
{ 
out [i] = a[i] ^ b[i]; 
} 
} 


void print_hex(char *str, unsigned char *buf, int len) 


{ 


int nee 
for ( i20; i<len; i++ ) { 
if ( (i © 16) == 0 && i != 0) printf(str); 
printf("$02x", buf[il); 
if ( (i % 4) == ) printf(" "); 
if ( (i % 16) == 15 ) printf("Nn"); 
) 
if ( (i$ 16) != 0 ) printf("Nn"); 
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void print128 (unsigned char *bytes) 
{ 
int Jå 
for (j=0; j<16;j++) { 
printf ("S02x",bytes[j]); 
if ( (j$4) == ) printf(" "); 


} 


void print96(unsigned char *bytes) 
{ 
int We 
for (j=0; j«12;j*-*) { 
printf ("S02x",bytes[j]); 
if ( (j$4) == ) printf(" "); 


) 
/* AES-CMAC Generation Function */ 


void leftshift onebit(unsigned char *input,unsigned char *output) 


{ 


int i 
unsigned char overflow = 0; 
for ( i=15; i»-0; i-- ) ( 
output [i] = input[i] << 1; 
output [i] |= overflow; 
overflow = (input [i] & 0x80) ?1:0; 
) 
return; 


} 


void generate_subkey (unsigned char *key, unsigned char *K1, unsigned 
char *K2) 
{ 
unsigned char L[16]; 
unsigned char Z[160]; 
unsigned char tmp[16]; 
int. i} 


for ( i20; i«16; i++ ) Z[i] = 0; 


AES 128 (key,2,L); 


if ( (L[0] & 0x80) == ) ( /* If MSB(L) = 0, then Kl = L << 1 */ 
leftshift onebit (L,K1l); 
) else ( /* Else Kl = ( L << 1 ) (+) Rb */ 
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leftshift onebit (L,tmp); 
xor 128 (tmp, const_Rb,K1); 
) 


if ( (K1[0] & 0x80) == ) I 
leftshift onebit (K1,K2); 
) else ( 


leftshift onebit (K1,tmp); 
xor 128 (tmp, const Rb,K2); 
) 
return; 


} 


void padding ( unsigned char *lastb, unsigned char *pad, int length ) 
{ 
int 35 


/* original last block */ 
for ( j=0; j«16; j++ ) I 
if ( j « length ) { 
pad[j] = lastb[jl; 


} else if ( j == length ) { 
pad[j] = 0x80; 
) else ( 


pad[j] = 0x00; 
) 


) 
void AES CMAC ( unsigned char *key, unsigned char *input, int length, 


unsigned char *mac ) 


{ 


unsigned char X[16],Y[16], M_last[16], padded[16]; 
unsigned char K1[16], K2[16]; 
int n, Y, flag; 


generate subkey (key,K1,K2); 


n = (length+15) / 16; /* n is number of rounds */ 
if (n== ) I 
n = 1; 
flag = 0; 
} else { 
if ( (length%16) == ) ( /* last block is a complete block */ 
flag = 1; 
) else ( /* last block is not complete block */ 
flag = 0; 
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} 


if ( flag ) { /* last block is complete block */ 
xor 128(&input[16* (n-1)],K1,M last); 

) else ( 
padding (&input [16* (n-1)],padded, length%16) ; 
xor_128 (padded, K2,M last); 

} 


for ( i20; i«16; i++ ) X[i] = 0; 

for ( i20; i«n-1; i++ ) { 
xor 128(X,&input[16*i],Y); /* Y := Mi (+) X */ 
AES 128 (key, Y,X); /* X := AES-128(KEY, Y); */ 


} 


xor 128(X,M last,Y); 
AES 128 (key,Y,X); 


for ( i20; i«16; i++ ) { 
mac[i] = X[il; 


} 


int main() 


unsigned char L[16], K1[16], K2[16], T[16], TT[12]; 
unsigned char M[64] = { 
Ox6b, Oxcl, Oxbe, Oxe2, Ox2e, 0x40, Ox9f, 0x96, 
Oxe9, Ox3d, Ox7e, 0x11, 0x73, 0x93, 0x17, Ox2a, 
Oxae, Ox2d, Ox8a, 0x57, Oxle, 0x03, Oxac, O0x9c, 
Ox9e, Oxb7, Ox6f, Oxac, 0x45, Oxaf, Ox8e, 0x51, 
0x30, Oxc8, Oxlc, 0x46, Oxa3, Ox5c, Oxe4, 0x11, 
Oxe5, Oxfb, Oxcl, 0x19, Oxla, Ox0Oa, 0x52, Oxef, 
Oxf6, Ox9f, 0x24, 0x45, Oxdf, Ox4f, Ox9b, 0x17, 
Oxad, Ox2b, 0x41, Ox7b, Oxe6, Ox6c, 0x37, 0x10 
E 
unsigned char key[16] = ( 
Ox2b, Ox7e, 0x15, 0x16, 0x28, Oxae, Oxd2, Oxa6, 
Oxab, Oxf7, 0x15, 0x88, 0x09, Oxcf, Ox4f, Ox3c 


printf("\nSubkey Generation Nn"); 

AES 128 (key, const_Zero,L); 

printf("AES 128(key,0) "); print128(L); printf("\n"); 
generate subkey (key,K1,K2); 
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printf("K1 "); print128(K1); printf("Nn"); 
printf("K2 "); print128 (K2); printf("\n"); 


printf("\nExample 1: len = 0n"); 
printf ("M "); printf ("<empty string>\n"); 


AES CMAC (key,M, 0, T) ; 
printf("AES CMAC "); print128(T); printf ("in"); 


printf("NnExample 2: len = 16\n"); 


printf ("M "); print_hex(" ",M,16); 
AES CMAC (key,M,16,T); 

printf("AES CMAC "); print128(T); printf("\n"); 
printf("NnExample 3: len = 40\n"); 

printf ("M "); print_hex(" ",M, 40); 
AES CMAC (key, M, 40, T) ; 

printf("AES CMAC "); print128(T); printf("\n"); 


printf("NnExample 4: len = 64\n"); 


printf ("M "); print_hex(" ",M, 64); 
AES CMAC (key,M, 64,T); 

printf ("AES CMAC "); print128(T); printf("\n"); 
printf("-------------------------------------------------- in") 


return 0; 
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